src/Microsoft.DotNet.Helix/AzureDevOpsTestPublisher/AzureDevOpsResultPublisher.cs:553

• GetRetryCount checks method == HttpMethod.Get, which can miss logically-GET methods created via new HttpMethod("GET") (or other equivalent instances). This can incorrectly disable retries for GET requests when RetryWrites is false; compare by value instead of reference.

    internal static int GetRetryCount(HttpMethod method, bool retryWrites)
        => retryWrites || method == HttpMethod.Get ? 10 : 0;

src/Microsoft.DotNet.Helix/AzureDevOpsTestPublisher/AzureDevOpsResultPublisher.cs:553

• GetRetryCount uses method == HttpMethod.Get, which is reference equality for HttpMethod. This returns false for new HttpMethod("GET") (and any non-cached instance), disabling retries for safe read-only GETs and causing the new unit test to fail. Use Equals (or compare method.Method) instead.

    internal static int GetRetryCount(HttpMethod method, bool retryWrites)
        => retryWrites || method == HttpMethod.Get ? 10 : 0;

src/Microsoft.DotNet.Helix/JobMonitor/TestResultUploadQueue.cs:27

• The file header summary still says uploads have “indefinite retry on transient errors”, but the new implementation retries only bounded read-only operations and attempts state-changing AzDO operations once (to avoid replaying ambiguous writes). Updating the summary here will prevent confusion later.

    /// </summary>
    internal sealed class TestResultUploadQueue
    {
        private const int MaximumTransientAttempts = 3;
        private const string AzdoWarningPrefix = "##vso[task.logissue type=warning]";

src/Microsoft.DotNet.Helix/JobMonitor/TestResultUploadQueue.cs:225

• The warning log message says “The run remains untagged … may retry the upload” even when the failure happens before any test run is created (testRunId=0), which is confusing. Consider emitting a different message when no run exists yet.

                    _logger.LogWarning(ex,
                        "{Prefix}Failed to {OperationDescription} for job {JobName}. Test run ID was {TestRunId}. "
                        + "{FailureKind} The run remains untagged and a later monitor invocation may retry the upload.",
                        AzdoWarningPrefix,
                        operationDescription,

src/Microsoft.DotNet.Helix/JobMonitor/TestResultUploadQueue.cs:235

• The warning message assumes "The run remains untagged" even when no test run has been created yet (e.g., download failures with testRunId==0), and it also asserts an untagged state that may not be true after an ambiguous completion/tagging failure. This can mislead troubleshooting; consider wording that’s conditional/hedged while still indicating that a later monitor invocation may retry the upload.

                        ? "Transient retry limit reached."
                        : "The operation may have partially completed and is not safe to replay in this invocation."
                    : "The failure is not retryable.";
                _logger.LogWarning(ex,
                    "{Prefix}Failed to {OperationDescription} for job {JobName}. Test run ID was {TestRunId}. "

src/Microsoft.DotNet.Helix/JobMonitor/TestResultUploadQueue.cs:235

• The warning message here always mentions a "test run" and "The run remains untagged" even when testRunId is 0 (e.g., during the download phase, before any run is created). That makes the log misleading and can confuse diagnosing failures.

Consider tailoring the message when no run exists yet (or omitting the test-run clause entirely for non-AzDO operations).

                _logger.LogWarning(ex,
                    "{Prefix}Failed to {OperationDescription} for job {JobName}. Test run ID was {TestRunId}. "
                    + "{FailureKind} The run remains untagged and a later monitor invocation may retry the upload.",
                    AzdoWarningPrefix,
                    operationDescription,

src/Microsoft.DotNet.Helix/JobMonitor/MonitorState.cs:170

• AddProcessedHelixJobs seeds durable completion state from existing AzDO tags, but it does not increment _processedJobCount. As a result, StatusReporter will treat these jobs as processed (via IsHelixJobProcessed), while the final summary uses ProcessedJobCount and may report 0 processed jobs even when everything was already processed before this invocation.

        public void AddProcessedHelixJobs(IEnumerable<string> jobNames)
        {
            lock (_sync)
            {
                foreach (string jobName in jobNames)
                {
                    _testResultUploadStates[jobName] = TestResultUploadState.DurablyCompleted;
                }

src/Microsoft.DotNet.Helix/JobMonitor/TestResultUploadQueue.cs:235

• The warning emitted on failure always says "The run remains untagged" even when the failure occurs before any test run exists (e.g., download failures where testRunId is 0). This can mislead diagnosis in AzDO logs. Consider wording this in terms of "durable tagged completion" rather than implying an existing run.

                _logger.LogWarning(ex,
                    "{Prefix}Failed to {OperationDescription} for job {JobName}. Test run ID was {TestRunId}. "
                    + "{FailureKind} The run remains untagged and a later monitor invocation may retry the upload.",
                    AzdoWarningPrefix,